【レポート】Scaling on AWS for the first 10 million users #AWSreInvent #ARC201

こんにちは。クラスメソッドのハウンです🐏

今回の記事では、AWS re:Invent 2024「1,000万ユーザーのためのAWS拡張」セッションのレポートを書いていきます。

本セッションは、AWSサービスを利用してウェブサイトを構築する際、ユーザー数によってどのように構成が変化した方が良いかについて説明していました。セッションについての概要は以下です。

このセッションでは、AWSでビジネスインフラの急速な成長と成功を処理するためのパターンと手法について考えます。 拡張時期と拡張時期を考慮する方法、キャッシングが最も役に立つ部分、アプリケーションを新しいサービスに分離する過程を調べます。 すでに拡張の可能性が高いAWSサービスの活用法から分散システムパターンの設計方法まで、初期段階で一般的なインフラ問題を克服するのに役立つ様々な選択肢があります。 各ステップで発生する可能性のあるインフラストラクチャの問題を克服する方法を調べてみます。

セッション動画については YouTube に公開されてますので、ご参考まで。

セッション内容

ユーザー数 > 1

ウェブアプリケーション構築を前提に話を進めていきます。まずは、大きくフロントエンドとバッグエンドに分けて構成を考えていきます。

従来は、フロントエンドのホスティングのために Amazon EC2 - ELB - Amazon CloudFront 構成で構築していくことが一般的でしたが、最近はサーバーレスを中心としたサービスを使うことが増えているそうです。こちらのセッションでは、AWS Amplify Hostingを使うことを勧めていました。

バッグエンドに関しては、Amazon EC2, Amazon ECS/Amazon EKS/AWS Fargate, AWS Lambda など、様々なサービスから選ぶことになりますが、Amazon ECSと AWS Fargate の組み合わせがおすすめされてました。プロビジョニングや構成、拡張において、サービスで自動的に管理してくれるため、エンジニアが開発により集中できるとのことです。

APIの構築時に使うサービスには Amazon API Gateway, Application Load Balancer, AWS AppSyncがありますが、使用目的によってサービスを選びやすいようチートシートが共有されてました。

データベースでは、Amazon Aurora Serverless v2がおすすめされてました。コンピューティングをストレージとデータベースから分離し、需要に合わせてコンピューティングとストレージそれぞれ拡張ができるため、容量の管理が容易であるとのことです。

上記のサービスを反映したアーキテクチャ図がこちらになります！

ユーザー数 > 10000

先ほどのアーキテクチャ図をもとにアプリケーションを運用していきますが、ユーザ数が増加するにつれて、アプリケーションの処理速度が遅くなったり、処理量に問題がある場合があると思います。この問題を解決するためにモニタリングが必要ですが、AWSで提供するモニタリングサービスであるAmazon CloudWatchとAWS X-Rayを活用して分析することができます。

そして、ユーザー数が増えることにより、データベースの拡張も考慮する必要があります。Amazon Aurora Serverless v2の拡張機能や容量の変更を試みたり、災害対策のためリードレプリカの導入などが方法として説明されてました。

AWS RDS Proxyを使用してリードレプリカを統合したり、セキュリティや性能を向上させることもできるとのことです。

最後に、データベースのクエリを自動化するため、Amazon ElastiCacheを使うことも勧めていました。

上記の内容を反映すると、アーキテクチャ図がこのように変化します。

ユーザー数 > 1000000

ユーザー数が百万、千万と増えてくると、会社の規模もその分大きくなるはずです。そのためにマイクロサービスを使うことを考慮する必要があります。

データベースを機能ごとに分離することや、NoSQL(Amazon DynamoDB)で大量のデータをより速く処理させたり、特殊目的のデータベースに切り分けて使うことも一案として紹介していました。

バックエンドに関しては、アプリケーションをデータのパターンに合わせて新しい連合サービスに分割したり、内部API基盤のサービスを利用して非同期式に変更することを勧めていました。

コスト削減のため、Amazon SNS, Amazon SQS, Amazon Kinesis Data Streamsを使うこともできます。

そして、これらの全てが反映されたアーキテクチャ図がこちらとなります！

最後に

このセッションのテーマについて、入社した年にもセッションレポートで書き上げた記憶がありますが、今回改めてこのテーマでブログを書いてみて構築の動向が変化したことがわかりました。最近では、アプリケーション設計の動向がAWS Amplify、AWS Fargateのようなサーバーレスサービスを中心とした構築が主流となっていると感じてます。

また、AWS DevOps Professional試験に出題されたサービスが多く出てきて、試験内容を復習できる機会になったセッションでした。エンジニアがアプリケーション開発に集中できるように、自主的に管理してくれるサービスを中心とする設計に変化したということは、AWSサービスもそれだけ発展したということを証明しているようで、技術の変化は本当に速いと感じました。